home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Loadstar 13
/
013.d81
/
dos #34
< prev
next >
Wrap
Text File
|
2022-08-26
|
4KB
|
184 lines
======================================
DOS & Don'ts -- Part 34
by James Gregory Weiler
======================================
Part C: The BAM in depth
(See map 2a: track bit maps)
Now, here's how we can use just four
bytes of the BAM to represent a whole
track containing up to 5376 bytes.
Let's look at just one set of four
bytes, the four that represent track
one. Remember, numbers that we
precede with a dollar sign are HEX
(base 16) numbers.
Byte 4 Byte 7 Byte 6 Byte 5
$15 $1F $FF $FF
Byte four is the block counter and
bytes five through seven are the track
bit map. We already know that track 1
has 21 blocks in it, blocks 0 through
20. The number in byte 4 tells us how
many blocks are unused on track 1.
$15 (hex) is 21 decimal -- so 21 of
the 21 blocks in track 1 are unused.
Which twenty-one aren't used? That's
what the other three bytes tell us.
Each bit in each byte represents one
block, so let's print out bytes five
through seven in binary so we can see
all the bits.
Byte 7:$1F Byte 6:$FF Byte 5:$FF
00011111 11111111 11111111
Now, starting at the right, and
starting with zero (because blocks on
a track start with number zero), count
the ones. There are 21, numbered zero
through twenty. One for each block on
the track.
Whenever we SAVE a program, DOS
keeps track of which blocks the
program was saved in by changing the
appropriate ones to zeros in the
track bit maps for the tracks where
the program was saved. That sound
like gobbledygook to you, too? Here's
an example.
Let's say you saved a program that
is two blocks long and DOS decided to
put it on track 0 block 3, and track 0
block 6.
Besides placing the program on track
zero, DOS has to update the track zero
bit map. Since it used blocks 3 and
6, it has to change the bits that
represent those blocks from ones to
zeros. Blocks 3 and 6 are represented
by the third and sixth bits from the
right in our charts. DOS also needs
to subtract two from the block counter
for track one, because it used two of
the available blocks. Here's a chart:
--------------------------------------
TRACK BIT MAP OF TRACK ZERO
byte 4 byte 7 byte 6 byte 5
{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}{CBM-T}
BEFORE SAVING
$15 $1F $FF $FF
00010101 00011111 11111111 11111111
AFTER SAVING
$13 $1F $FF $B7
00010011 00011111 11111111 10110111
--------------------------------------
Map 2a shows you what the track
bit maps look like on a disk that
has no files on it. Bytes zero and
three of the track bit maps are
different from track to track because
different tracks have different
numbers of blocks.
======================================
Map 2a: representative track bit map.
byte description
--------------------------------------
0 Free Block Counter
1 Map of sectors 0-7
2 Map of sectors 8-15
3 Map of sectors 16-20
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Track bit maps for empty tracks:
byte 3 byte 2 byte 1 byte 0
------- -------- -------- --------
tracks
1-17 $1F $FF $FF $15
00011111 11111111 11111111 00010101
18-24 $07 $FF $FF $13
00000111 11111111 11111111 00010011
25-30 $03 $FF $FF $12
00000011 11111111 11111111 00010010
31-35 $01 $FF $FF $11
00000001 11111111 11111111 00010001
21111 11111198 76543210 block
09876 543210 represented
=======< continued in Part 35 >=======